Explain the concept of include and extends in consideration with use case scenario with example.

«Include» and «Extend» Relationships in Use Case Diagrams

In UML use case modeling, the «include» and «extend» relationships are important concepts that help manage complexity and reduce redundancy in use case diagrams by showing how use cases relate to each other.

The «Include» Relationship

The «include» relationship indicates that a base use case explicitly incorporates the behavior of another use case at a specific location in its sequence. It represents mandatory behavior - the included use case will always be executed when the base use case is performed.

Key Characteristics of «Include»:

1. Mandatory Execution: The included use case is always executed when the base use case runs
2. Reuse of Functionality: Helps avoid duplication by extracting common behavior into separate use cases
3. Simplification: Makes complex use cases more manageable by breaking them into smaller parts
4. Direction: The arrow points from the base use case to the included use case
5. Notation: Represented as a dashed arrow with the stereotype «include»

Example of «Include» Relationship:

In an online banking system:

┌──────────────────────────────────────────────────────────┐
│                     Online Banking System                 │
│                                                          │
│    ┌──────────────┐       «include»       ┌────────────┐ │
│    │              ├─────────────────────► │            │ │
│    │ Transfer     │                       │ Verify     │ │
│    │ Funds        │                       │ User       │ │
│    │              │                       │            │ │
│    └──────────────┘                       └────────────┘ │
│                                                          │
│    ┌──────────────┐       «include»                      │
│    │              ├─────────────────────┐                │
│    │ Pay Bills    │                     │                │
│    │              │                     │                │
│    └──────────────┘                     ▼                │
│                                    ┌────────────┐        │
│                                    │            │        │
│                                    │ Log        │        │
│                                    │ Transaction│        │
│                                    │            │        │
│                                    └────────────┘        │
└──────────────────────────────────────────────────────────┘

In this example:

• Both "Transfer Funds" and "Pay Bills" include "Verify User" - User verification is a mandatory part of performing these operations
• "Pay Bills" also includes "Log Transaction" - Transaction logging is always performed when paying bills

The «Extend» Relationship

The «extend» relationship indicates that a base use case may be augmented by another use case under specific conditions. It represents optional behavior that may or may not occur, depending on certain conditions.

Key Characteristics of «Extend»:

1. Conditional Execution: The extending use case is only executed if specific conditions are met
2. Optional Behavior: Represents behavior that may not always occur
3. Extension Points: Defines where in the base use case the extension may be inserted
4. Direction: The arrow points from the extending use case to the base use case
5. Notation: Represented as a dashed arrow with the stereotype «extend»

Example of «Extend» Relationship:

In an e-commerce system:

┌──────────────────────────────────────────────────────────────┐
│                      E-Commerce System                        │
│                                                              │
│    ┌────────────────┐                   ┌────────────────┐   │
│    │                │      «extend»     │                │   │
│    │ Checkout       │◄─────────────────┤ Apply Discount │   │
│    │                │                   │                │   │
│    │ Extension points:                  │                │   │
│    │ - Calculate total                  └────────────────┘   │
│    └────────────────┘                                        │
│                                                              │
│                                                              │
│    ┌────────────────┐                   ┌────────────────┐   │
│    │                │      «extend»     │                │   │
│    │ Process        │◄─────────────────┤ Verify Credit  │   │
│    │ Payment        │                   │ Card           │   │
│    │                │                   │                │   │
│    │ Extension points:                  └────────────────┘   │
│    │ - Payment method                                        │
│    └────────────────┘                                        │
└──────────────────────────────────────────────────────────────┘

In this example:

• "Apply Discount" extends "Checkout" - Discounts are only applied if the customer has a valid discount code
• "Verify Credit Card" extends "Process Payment" - Credit card verification only occurs if the customer chooses to pay by credit card

Comparing «Include» and «Extend» Relationships

Aspect	«Include»	«Extend»
Nature	Mandatory behavior	Optional behavior
Direction	Base use case → included use case	Extending use case → base use case
Purpose	Reuse common functionality	Add optional behavior
Execution	Always executed	Executed only if conditions are met
Control	Base use case controls when included use case executes	Base use case may be unaware of extension
Usage	Extract common functionality	Handle alternative flows and exceptions

When to Use Each Relationship

Use «Include» when:

• The same functionality appears in multiple use cases
• A complex use case needs to be broken down into more manageable parts
• You want to explicitly show that a certain functionality is always performed

Use «Extend» when:

• Behavior is optional and occurs only under certain conditions
• You want to separate exceptional or alternative flows from the main use case
• Additional functionality might be added to a use case without modifying it

Both relationships help in creating more modular, maintainable use case models that accurately represent the behavior of complex systems while remaining understandable to stakeholders.